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1.0 Introduction 

The Low Cost Booster Project (LCBP), also known as Bantam, is an element of the Advanced 
Space Transportation Program focused on Low Cost Booster Technologies. During FY 00 flight 
demonstrations are planned to demonstrate the feasibility of producing a booster capable of insert- 
ing a 150 kg payload into low earth orbit. The ground support system is an element of the full 
launch system. The ground support system includes the Data and Command System (DCS), mis- 
sion planning system and simulation system. This report focuses on the DCS which provides for 
integration of the payload with the launch vehicle, preparation of the vehicle for launch (including 
maintenance, integration and test of the vehicle flight software), monitor and control of the launch 
sequence, range safety during launch, and collection of telemetry during the flight up to payload 
release. The ground support system is intended to make the maximum possible use of Govern- 
ment Off-the-Shelf (GOTS) or Commercial OfF-the-Shelf (COTS) hardware and software to ob- 
tain the best value in terms of development operations support and ultimate life cycle cost for the 
launch system. 

1.1 Purpose 

The purpose of this document is to provide an analysis of existing off the shelf products for the 
Bantam DCS. This constitutes the final report under Contract NAS8-97319. The information in 
this document has been collected with the goal of assisting the launch vehicle contractors with 
concepts which can be useful in structuring their ground systems, and data concerning potential 
off the shelf products which can be used to implement these systems. A typical system architec- 
ture is provided for reference and to establish a basis for configuration of the proposed vendor 
systems to make comparisons more consistent. This document contains high level summaries of 
the requirements document and operations concept produced earlier. Additionally, low cost com- 
munications concepts are discussed. The rankings of the products are provided to establish a 
context for discussion of the systems. In selecting these or other systems for use in their launches 
the contractors may weight evaluation criteria differently, depending on the needs of their own 
vehicle, and may consider other criteria in evaluating these products. 

1.2 Scope 

The elements covered in this document are the DCS hardware and software required to perform 
the direct launch support activities for the Bantam development vehicle. Personnel requirements 
are not directly addressed, although the selection of a ground support system could have a signifi- 
cant impact if it requires greater or lesser manpower to operate and/or maintain. This is factored 
in as a part of the evaluation criteria for the systems. It was also a fundamental consideration in 
identifying the system architecture which directly affects the costing of proposed systems. 
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2.0 Applicable Documents 


LCBT-PP 

MSFC-RQMT-2674A 

MSFC-SPEC-2675 
MSFC-DOC-2678 
NTI TR-1018 
NTI TR-1019 

W-7-NA-71011 

W-7-NA-71011 


LCBT Program Plan 

Low Cost Booster Program (LCBP) Propulsion Test Article 
(PTA1) Systems Requirements Document 

LCBT Fastrac 60K Engine Specification 

LCBT Fastrac 60K Engine Interface Definition Document 

Bantam System Technology Project, Ground System Requirements 

Bantam System Technology Project, Ground System Operations 
Concept and Plan 

Candidate Bantam System Operations Concept, Universal Space 
Lines, Inc. 

Bantam NRA 8-15 November 1997 Report, Universal Space Lines, 
Inc. 

Discovery Mission Operations Handbook, NASA Jet Propulsion 
Laboratory, April 1994 

Low Cost Mission Operations Workshop; NASA Jet Propulsion 
Laboratory, April 1994 

Satellite Operations: Determining a Path to the Future; United 
States Air Force, Office of the Department of Defense Space 
Architect, September 1997 

New TDRSS Communications Options for Small Satellites; NASA 
Goddard Space Flight Center, 1996 
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3.0 Utilization of Study Results 


This study was intended for use as a tool in the analysis of candidate off the shelf systems for 
possible use as the basis for a Bantam Launch Control System. Every attempt was made to make 
the survey as complete as possible, but there may be other viable candidates available for such a 
system. Complete contact information is provided for each of the vendors surveyed. Although a 
ranking is presented we would expect that the prime contractors would choose a vendor based on 
their own unique needs and capabilities. 

3.1 Principles 

The fundamental principle of this study is to determine a DCS which represents the best value for 
the Bantam Program. The best value system is considered as that which delivers the required 
functionality in a reliable manner at the lowest overall life cycle cost. 

Low overall cost is emphasized by: 

• limiting the DCS requirements to those needed as opposed to those nice to have 

• acquiring a functional system as opposed to developing a system 

• minimizing the work required to integrate the system components internally and externally 

• ensuring that the system acquired will easily integrate within the overall ground system 

• ensuring that the system is easy to set up and operate 

• ensuring that the system provides for high operator productivity and effectivity 

• ensuring that the system is stable and can function without frequent updates/upgrades 
Reliability is emphasized by: 

• ensuring that the acquired system has been proven 

• ensuring that the system is based on components which are proven and stable 

• ensuring that system suppliers are well established and likely to be around if/when the system 
requires maintenance and/or upgrade. 

3.2 Procedures and Methods 

Several steps led to this report. First the fundamental requirements for the ground system were 
identified through analysis and discussions with spaceports, payload sponsors and vehicle manu- 
facturers. Next an operations concept was defined based on these inputs to provide insight into 
the probable implementation of the ground system. From these a candidate DCS architecture was 
defined which would meet these requirements. Finally a market survey was performed to identify 
potential products which could meet the requirements, using the proposed architecture as a basis 
to ensure that we were comparing relatively compatible versions of the vendor products. 
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4.0 Requirements Summary 


A proposed set of system requirements is presented as a guide for use in definition of the ground 
support system. For a detailed set of requirements see NTI-TR-1018. 


4.1 Overall 


Ground system requirements are defined to accept a payload with a detailed definition of its 
planned mission which is processed by the mission planning system to generate mission specific 
parameters for the flight software. These are checked and optimized through the mission simula- 
tor. When the payload is ready for launch it will be shipped to the launch site where the ground 
operations team will integrate the payload with its launch vehicle, prepare the vehicle for launch, 
control all aspects of the actual launch and collect telemetry as necessary to assess vehicle per- 
formance. 


4.2 Data and Command System 


The fundamental requirements are for the DCS system to monitor and control vehicle preparation 
for launch, interface to the vehicle for final flight software upload and launch release, monitor te- 
lemetry during the flight, provide appropriate support for the range safety function, and retain a 
detailed data archive of all activities and telemetry collected during the prelaunch and launch 
phases. The DCS provides the specific service required to control launch operations and collect 
associated data. The fundamental requirement is that the control center is able to monitor all re- 
quired operations and the associated data at all times during the launch sequence. The data itself 
is archived and maintained so that it can be analyzed during post flight operations with the pur- 
pose of improving operations and assessing the root causes of any mission failures. 


5.0 Operations Concept and Plan Summary 


The operations concept and plan provide a framework for alternative methodologies for imple- 
mentation of the system requirements. They provide a viewpoint which aids in assessment of 
proposed implementations using off the shelf components to accomplish the ground support mis- 
sion. 
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5.1 Overall 


The central concept of the Operations Plan is to achieve a low recurring cost through the optimal 
use of automated systems. The integrated ground system consists of three primary segments, the 
Mission Planning System, the Simulation System and the DCS. The Mission Planning System 
takes inputs from the payload sponsor and uses them to determine the parameters for the flight 
software to use for the launch. The Simulation System is used during the mission design phase to 
help define and test the flight software, and later during operations is closely coupled with the 
Mission Planning System to evaluate the generated parameters. The Data and Command System 
provides for monitoring and control of the vehicle during the prelaunch and launch processes. It 
uses the output from the mission planning system as an input to the vehicle during final flight 
software upload. 


5.2 Data and Command System 

To meet the Bantam objectives for efficiency and reliability the DCS is conceived as a highly 
automated, data driven system, capable of supporting multiple vehicles and short turnaround 
times with a small core cadre of operations personnel. The DCS also has additional functionality 
as a test monitor during vehicle production. This provides efficiency in developing only a single, 
consistent set of tests for system and subsystem checkout from manufacturing all the way through 
launch. It also ensures that built in and DCS controlled tests are fully checked out well before the 
first launch. 

The project launch support crew is projected to be two to three controllers, each with an inde- 
pendent workstation. Launch processing is automated and includes appropriate displays to keep 
the operators fully informed on the progress of the launch activities and on caution and warning 
systems to detect and display problems. Complete data archiving is provided to ensure that 
anomalies can be resolved and to provide the basis for simulation updates and launch crew train- 
ing. Positive control of the launch process will be maintained through procedural holds and the 
capability for manual aborts at any time. 

Data is collected and displayed during the flight phase, but except for range safety destruct 
mechanisms no commands are sent to the vehicle. All telemetry is logged and archived. The pri- 
mary mechanism for anomaly resolution is postflight analysis of this data, so although it may be 
displayed in real time, the display is for information only except for any data provided to the range 
safety function. 

6.0 Data System Architecture 

The overall Ground System Architecture and the DCS Architecture were developed to satisfy the 
requirements in the Ground System Requirements document, based on the concepts in the Opera- 
tions Concept and Plan. Additionally they are in concert with the concepts presented in the Uni- 
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versal Space Lines documents. 


6.1 Overall 


The Ground System as a whole consists of three primary components, the Mission Planning Sys- 
tem (MPS), the Simulation (SIM), and the Launch Control Center which is facilitated/automated 
by the DCS. These are illustrated in Exhibit 6.1-1. The MPS and SIM are closely coupled, as the 
simulation is an integral part of the process of mission analysis. The primary reason they are con- 
sidered separate is that the simulation will almost certainly be developed as an independent system 
and it has significant uses outside of the mission planner. The Data and Command System is that 
portion of the ground system which actually controls the test, prelaunch and launch processes. 
The DCS architecture is required to interface with and facilitate the overall Ground System. 



Exhibit 6.1-1 Ground System Overview 


6.2 Data and Command System 

The data and command system is concerned with two primary functions, first to monitor and 


8 
















control the events leading up to the launch of the vehicle, and second, to receive, display and rec- 
ord telemetry data from the vehicle in flight. The DCS may also provide interfaces for remote 
monitoring of launchsite activities. Typically it consists of hardware interfaces to the vehicle and 
ground support equipment on the pad, and a radio frequency (RF) telemetry link with the vehicle 
for collection of in flight data, as illustrated in Exhibit 6.1-1. The data collected from either the 
ground or flight instrumentation is time tagged and recorded by the DCS for post flight analysis. 

7.0 Market Survey 

7.1 Approach 

To conduct the market survey, we contacted multiple organizations identified with spacecraft and 
launch command and control. In addition, we took an extensive look at companies providing te- 
lemetry products. The most fruitful search methodology proved to be use of the Internet to find 
companies advertising their wares. All of the major players have web sites, and these were often 
informative. 

The data contained in our Requirements and Operations Concept documents was used to define 
the basis for analysis of the proposed systems from the various vendors. Criteria used for evalua- 
tion were of two different types, pass-fail requirements and subjective criteria. Finally cost rank- 
ings were generated for the surveyed products. 

7.1.1 Pass-Fail Criteria 

The following table (Exhibit 7.1-1) identifies the individual requirements which each product was 
evaluated against. It should be noted that some of these requirements are met by elements outside 
of the normal function of the products evaluated. For example, the range safety function is out- 
side of the normal launch control system area of direct responsibility. Configuration management 
is normally provided by a separate product. All of these were included because some of the sys- 
tems evaluated had notable contributions in these areas, and we wanted to ensure completeness of 
our requirements evaluation. 


Requirement 

Generic 

• Configurable to support any Bantam vehicle 

• Adaptable to all spaceports 

Monitor and display status of all physical interfaces 


Monitor and display status of flight software 
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Configuration Management 
must be handled by the ground 
system, but not necessarily di- 
rectly by the DCS application 

Verify correct upload of mission specific software/data 
Launch sequence monitor and control of: 

• Ground equipment (interface units, sensors, voice and 
video, electrical systems, fire suppression, weather) 

• All prelaunch vehicle servicing (cryo, propellants, gasses, 
etc) 

• Launch vehicle health and status (built in test initiation 
and monitoring) 

• Launch vehicle internal sensors (built in test) 

• OBC checkout and monitor 

• Software/data upload verification 

• RF downlink interfaces for payload and vehicle 

• Payload health and status 

Launch sequence manual control must provide 

• Preplanned holds 

• Manual abort at any time (with checks to ensure proper 
safing etc.) 

• Final launch initiation 

• Appropriate range safety interfaces for prelaunch phase 

Recording of all vehicle to ground system information passed, 
with time tags 

Capability to archive and retrieve recorded data 
Interface to telemetry collection for launch data 


Provide positive management and control of mission 
specific software/data 
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Support for range safety function 


Range safety typically is an in- 
dependent function, apart from 
our DCS system, though they 
should communicate 


Exhibit 7.1-1 - Pass-Fail Criteria 


7.1.2 Subjective Criteria 

The subjective criteria below were used to provide differentiation among the products based on 
factors other than the ability to meet the system requirements. These take into account value 
added aspects of the products such as the degree of automation of the system, and risk factors 
such as supplier stability and product maturity. 


• Supplier stability - ability to provide ongoing level of maintenance for life of program 

This is an important criterion, but one which has some conflicting issues. It is possible that 
the lowest cost solution could come from a startup company which is hungry for the business 
and willing to go an extra mile to get it. Innovative solutions are certainly likely from these 
small companies. It should be noted that all of the commercial players in this evaluation are 
small companies. The dominant factor in the ranking as presented is the risk associated with 
supporting the product over a long life cycle. 

level 1 - Startup company with low capitalization and no viable work beyond this 
contract 

level 2 - New company with other work, but little track record 
level 3 - Established company with multiple other related contracts 
level 4 - Established company with multiple product lines and contracts 
level 5 - Major corporation with multiple product lines and contracts 

• Maturity - degree to which proposed system has been tested, used and/or exercised 

Until recently the launch control function remained with the government or the vehicle manu- 
facturer, and there were no off the shelf products. The majority of the off the shelf products 
which have emerged had their origins in test control, satellite control or both. Actual launch 
vehicle control experience is very limited. Therefore this is a strong discriminator. There is 
an open question to a certain extent whether a product based on an existing launch control 
technology but with no operational experience should be rated higher than one with demon- 
strated success in a different field. 

level 1 - Custom product 

level 2 - New product in first release 
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level 3 - New product based on existing system with successful history 
level 4 - Off the shelf product with demonstrated success in related applications 
level 5 - Off the shelf product with demonstrated success in the same application 
Configurability - ease of adapting to different missions 

The inherent needs of the field dictate a similar approach to configurability among the con- 
tenders. In order to be a viable product it is necessary to provide certain core capabilities, 
thus a modular design is the most common. Preference is shown toward an open systems ap- 
proach, since the use of COTS products from other vendors to enhance the system provides 
an easy upgrade path when better capabilities come onto the market. More importantly, this 
eases the integration of the DCS with the other elements of the Ground Operations System. 

level 1 - Custom design for each mission 

level 2 - Component design adapted for each mission 

level 3 - Component design with strong Applications Program Interfaces (APIs) and 
tools provided 

level 4 - Generic with APIs and existing interfaces to commonly required COTS 
products 

Adaptability - support of different launch vehicles 

This is an area where there is little difference among the viable contenders. All of the pro- 
posed solutions use a component design, and all will require some degree of development to 
adapt to the specific vehicles. Each includes tools to aid in this development. 

level 1 - Custom design for each vehicle 

level 2 - Component design adapted for each vehicle 

level 3 - Component design with APIs and tools for adapting to vehicles 

level 4 - Component design with existing tools for most vehicles 

Expandability - ability to extend capabilities as required 

The fact that each of the proposed solutions is already modular indicates that this is an inher- 
ent capability for all of them. Some may have a greater flexibility, and possibly more proven 
interfaces. CORBA compliance extends computability with other software packages, possibly 
at the cost of performance. This criteria should be questioned by the raters as to its applica- 
bility to their design. 

level 1 - Custom software 

level 2 - Some components available for common functions 
level 3 - Multiple components with APIs available 

level 4 - Multiple components, multiple existing COTS interfaces, well documented 
APIs 

level 5 - All potential needs can be met from single source, with COTS interfaces pre 



done and fully functional. CORBA compliant 

• Ease of use - clear user interfaces, intuitive displays and configurable output 

This is not just an appearance issue. In order to allow operation of the system with a small 
core of operators it is necessary to provide intuitive, easily understood user interfaces. The 
operator must be presented with information as clearly as possible to enable adequate control. 

level 1 - Required displays provided through custom interface 

level 2 - Multiple standard displays provided covering basic functionality 

level 3 - Multiple displays with APIs for third party user interface 

level 4 - Multiple displays, APIs and very adaptable displays 

level 5 - Full set of predefined displays, capability for operator to customize for his 
own applications 

• Automation - usable by small cadre of console operators 

This evaluation factor is one of the most important discriminators. Our emphasis is on reduc- 
ing recurring costs for the operational phase of the program, and one of the primary ways of 
accomplishing this is to perform our launches with the minimum manpower level. This re- 
quires automated systems which reduce the workload and increase the handling capacity for 
the operators. Approaches which have been proposed include scripting capabilities for the 
system, active limit sensing and handling, and artificial intelligence approaches. 

level 1 - Primarily manual monitor and control 

level 2 - Efficient setup to ease operator load, still a level of manual control 


level 3 - System procedurally automated 

level 4 - Automated procedures, limits and sensing, system aids operator in visualizing 
and handling anomalies 

level 5 - Fully automated system, operator intervention only at preplanned points 

• Integration - single provider has full range of hardware and software solutions 

A fully integrated system has the benefit of allowing the developer to concentrate on vehicle 
specific development and not worry about integrating hardware and software. 

level 1 - Hardware or software only 

level 2 - Hardware or software with cooperative agreements for integration 

level 3 - Produces most equipment and software, some external 

level 4 - Produces most required ground support equipment with custom integration 
required 

level 5 - Turnkey operation, all hardware and software fully integrated 

• Platform availability - availability on variety of computational platforms 
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level 1 - Single platform dependent 

level 2 - Cross platform, single operating system (non UNIX) 

level 3 - Cross platform, UNIX 

level 4 - Multiple platform, UNIX and Windows NT 

Once a ranking against the factors presented is accomplished the scores must be normalized, since 
the scales are not equal. This is accomplished by defining a scaled score which is essentially the 
raw score as a percentage of the maximum possible score. Finally a weighting factor must be as- 
signed to each of the factors since they are simply not equally important. 

7.1.3 Weighting of Subjective Criteria 

Each of the criteria above, except cost, was assigned a weight. The sum of the weights is 100 so 
that each may be considered to be a percentage assigned to the criterion. When the weights are 
multiplied times the scaled scores, the result is a weighted score. The maximum possible score 
per criteria is 4 or 5, depending on the criteria. The weighted score is determined by the follow- 
ing formulas: 

Scaled Score = (Raw Score / Maximum Possible Score) expressed as a percent 
Weighted Score = Scaled Score * Weight 


The following table defines the weights we assigned to each of the factors: 


Evaluation Criteria 

Weight 

Rationale 

Supplier stability 

10 

This is given a moderate weight as we felt that it is 
important to ensure ongoing support for our system 
through the operational phase 

Product Maturity 

15 

This was highly rated to reflect the belief that a ma- 
ture system is more likely to support the short devel- 
opment schedule of Bantam, and will be more stable 
as a product. It also should increase overall reliabil- 
ity over the long term. 

Configurability 

5 

This reflects the component nature of the product 
and the ability to add on other components. This is a 
fairly important factor, but not a significant discrimi- 
nator among the evaluated systems 

Adaptability 

15 

This feature captures the ease of system development 
contained within the product. 

Expandability 

5 

We expect the DCS to remain stable after the initial 
development, and do not expect there will be a sig- 
nificant need to expand the capabilities 

Ease of use 

15 

This is largely related to the operator friendly fea- 
tures of the system, and was rated high as anything 
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which reduces operator workload and increases 

Automation 

15 

This feature is important to allow the DCS to func- 
tion with a minima] crew and to allow operations 
without the use of highly specialized personnel 

Integration 

15 

The emphasis here is on the ability to minimize the 
effort to integrate the system internally and externally 

Platform availability 

5 

Availability over a variety of hardware platforms 
provides flexibility in implementation 


7.2 Systems Surveyed 


The following companies were interviewed and product demonstrations viewed: 

Altair Aerospace Corporation, Bowie MD 

Command and Control Technologies Corporation, Titusville, FL 

Integral Systems, Inc, Lanham, MD 

L3 Communications, San Diego, CA 

Storm Integration, Inc, Herndon, VA 

Software Technology, Inc, Melbourne, FL 

Veda Systems, Inc, California, MD 

In addition government organizations were contacted for data on the possibility of using govern- 
ment off the shelf items. It should be noted that at least one of the products above was a govern- 
ment system being sold under a technology license from NASA. 


7.2.1 Commercial Off the Shelf Systems 


In order to provide a valid comparison among the various systems under consideration a common 
configuration was defined to represent the standard ground system. This configuration is for a 
single stream of telemetry data, required workstations and software to provide support to a three 
operator ground station, and appropriate hardware. In the final cost rankings only the software 
was quoted, except as noted, as each of the systems is capable of supporting any telemetry ac- 
quisition system. The ability of several of the vendors to provide a turnkey system is desirable, 
and this is captured in the integration score in the performance rating section. 


All prices given are list prices for off the shelf items, and none of the estimates include costs for 
mission unique development. To a certain extent this cost is considered in the subjective evalua- 
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tion. Those systems with high ratings for configurability, ease of use and automation could be 
expected to have lower costs associated with the mission unique development. 
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7.2. 1.1 Altair Aerospace Corporation 


Altair is a small company, currently with about 35 employees, experiencing rapid growth. They 
are well established, with multiple significant contracts currently active, and have an experienced 
and effective engineering organization. They have the capability to provide a completely turnkey 
system, and have done so for some satellite ground stations. They are among the few vendors 
with actual launch control experience with their system, having used it to support the Connestoga 
launch. 


Criteria 

Met 

Comments 

Generic 



• Configurable to support any Bantam 
vehicle 

✓ 


• Adaptable to all spaceports 

✓ 

Altair has a very open architecture, with 
powerful modeling tools for adapting to 
multiple vehicle support. They are currently 
involved with ground system setups at Flor- 
ida and Akjuit space ports 

Monitor and display status of all physical 
interfaces 

✓ 


Monitor and display status of flight soft- 

✓ 


ware 



Provide positive management and control 
of mission specific software/data 


No built in CM tools, expect user to supply 
this function 

Verify correct upload of mission specific 
software/data 

✓ 

Specific support for mission software man- 
agement 

Launch sequence monitor and control of: 



• Ground equipment (interface units, 
sensors, voice and video, electrical 
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systems, fire suppression, weather) 

• All prelaunch vehicle servicing (ciyo, V 
propellants, gasses, etc) 

• Launch vehicle health and status (built V 
in test initiation and monitoring) 

• Launch vehicle internal sensors (built / 
in test) 

• OBC checkout and monitor / 

• Software/data upload verification •/ 

• RF downlink interfaces for payload and •/ 
vehicle 

• Payload health and status / 

Launch sequence manual control must 
provide 

• Preplanned holds / 

• Manual abort at any time (with checks </ 
to ensure proper safing etc.) 

• Final launch initiation S 

• Appropriate range safety interfaces for >/ 
prelaunch phase 

Recording of all vehicle to ground system •/ 
information passed, with time tags 

Capability to archive and retrieve recorded V 
data 

Interface to telemetry collection for 
launch data 

Support for range safety function 


Multiple time types 


Provided direct range safety support on 
Conestoga 
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Evaluation Criteria 


Evaluation Criteria 

Raw 

Score 

Scaled 

Score 

Supplier stability 

3 

60 

Product maturity 

5 

100 

Configurability 

4 

100 

Adaptability 

3 

75 

Expandability 

4 

80 

Ease of use 

4 

80 

Automation 

5 

100 

Integration 

5 

100 

Platform availability 

4 

100 

Total Score 



Cost 


S/W 

70,000 


19 


Weighted Comments 
Score 


6 


15 

This is one of the most mature prod- 
ucts in the survey, having been used 
on multiple existing systems and in 
an actual launch system application 

5 


11.25 


4 


12 


15 

The basis of the automation of the 
system is in the use of operational 
models which incorporate state rec- 
ognition and state transition func- 
tions to monitor and control activi- 
ties. This is a significant difference 
from other vendors approaches. 

15 

Altair has the capability to deliver a 
fully integrated turnkey system 

5 

Multiple platforms, Unix and NT 

88.25 

















































7. 2.1.2 Command and Control Technologies Corporation 


Command and Control Technologies is a startup company which has licensed an existing NASA 
tool and enhanced and expanded on its capabilities. The principals of the company are very expe- 
rienced in the launch control field, with direct experience applying the capabilities they are market- 
ing to launch operations. They have several other technology contracts with NASA in the field of 
launch support, not directly involved with this tool, and they continue to cooperate with the 
NASA engineers in developing their system. Another factor is that they are focused solely on 
launch systems, which ensures that they clearly understand exactly what is required for this spe- 
cific application. 


The first release of their product is not due till this summer, so it is untried. Since it is based on 
existing technology the element of risk is significantly reduced, but the full system is has never 
been actually implemented. The system has been used for launch control, so in that aspect it has 
some significant advantages over systems which are primarily from other areas and adapted for 
launch control. The first product which they are marketing is the core module of the system, and 
many capabilities would be required from other COTS software, for example the user interface. 
The demonstration included direct examples of interfaces with G2, an artificial intelligence engine, 
and Dataviews, which is widely used to provide GUI capabilities in this field. 


Criteria 

Met 

Comments 

Generic 



• Configurable to support any Bantam 
vehicle 

✓ 


• Adaptable to all spaceports 

✓ 


Monitor and display status of all physical 
interfaces 

✓ 


Monitor and display status of flight soft- 
ware 



Provide positive management and control 
of mission specific software/data 


No CM support, user to supply CM func- 
tions 
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Verify correct upload of mission specific 
software/data 


Launch sequence monitor and control of: 


• Ground equipment (interface units, 
sensors, voice and video, electrical 
systems, fire suppression, weather) 

s 

• All prelaunch vehicle servicing (cryo, 
propellants, gasses, etc) 

s 

• Launch vehicle health and status (built 
in test initiation and monitoring) 

s 

• Launch vehicle internal sensors (built 
in test) 

s 

• OBC checkout and monitor 

s 

• Software/data upload verification 

s 

• RF downlink interfaces for payload and 
vehicle 

s 

• Payload health and status 

s 

Launch sequence manual control must 
provide 


• Preplanned holds 

s 

• Manual abort at any time (with checks 
to ensure proper safing etc.) 

s 

• Final launch initiation 

s 

• Appropriate range safety interfaces for 
prelaunch phase 

s 

Recording of all vehicle to ground system 
information passed, with time tags 

s 

Capability to archive and retrieve recorded 
data 

y 
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Evaluation Criteria 

Raw 

Score 

Scaled 

Score 

Supplier stability 

2 

40 

Product Maturity 

4 

80 




Configurability 


Adaptability 


Expandability 


Ease of use 


Automation 


Integration 


Platform availability 


Startup with very experienced people, 
many from Delta Clipper 


System is licensed from NASA, has 
been used for launch control in past, 
major enhancements being made. 
Score was enhanced to reflect that the 
product has been used in launch ap- 
plications, not just related field 



NT port due at end of summer 



Specific costing depends on final 
configuration, exact figures were not 
available. Costs are estimated to be in 
line with the average cost for these 
types of systems. 
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7.2.1.3 Integral Systems, Inc 


Integra] Systems is a solidly established company providing satellite ground control stations for a 
variety of foreign and domestic satellite systems. Their system is mature and stable and has dem- 
onstrated reliability. 


Comments 


Criteria 

Met 

Generic 


• Configurable to support any Bantam 
vehicle 

✓ 

• Adaptable to all spaceports 

✓ 

Monitor and display status of all physical 
interfaces 

✓ 

Monitor and display status of flight soft- 
ware 

✓ 

Provide positive management and control 
of mission specific software/data 

✓ 

Verify correct upload of mission specific 
software/data 

✓ 

Launch sequence monitor and control of: 


• Ground equipment (interface units, 
sensors, voice and video, electrical 
systems, fire suppression, weather) 

✓ 

• All prelaunch vehicle servicing (cryo, 
propellants, gasses, etc) 

✓ 

• Launch vehicle health and status (built 
in test initiation and monitoring) 

✓ 

• Launch vehicle internal sensors (built 
in test) 

✓ 
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• OBC checkout and monitor 

s 

• Software/data upload verification 

V 

• RF downlink interfaces for payload and 
vehicle 

s 

• Payload health and status 

Y 

Launch sequence manual control must 
provide 


• Preplanned holds 

S 

• Manual abort at any time (with checks 
to ensure proper safing etc.) 

✓ 

• Final launch initiation 

✓ 

• Appropriate range safety interfaces for 
prelaunch phase 

S 

Recording of all vehicle to ground system 
information passed, with time tags 

V 

Capability to archive and retrieve recorded 
data 

S 

Interface to telemetry collection for 
launch data 

S 

Support for range safety function 



Evaluation Criteria 


Supplier stability 


Product maturity 


Configurability 


Adaptability 




Score 


Weighted Comments 
Score 


8 


12 


3.75 


11.25 
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Ease of use 

5 

100 

15 


Automation 

4 

80 

12 


Integration 

5 

60 

9 


Platform availability 

3 

75 

3.75 


Total Score 



78.75 


Cost 


S/W 

115,000 


This price is based on a three 
workstation configuration at 
35000 per workstation (hardware 
and software) 
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7.2.1.4 L3 Communications 


L3 Communications is primarily a supplier of hardware systems applicable to the ground control 
system function. For system software they normally team with Storm Control Systems to provide 
a total solution. Since most of the criteria in this evaluation are based on the functions of the 
software in the system we will defer this evaluation to the Storm section. 


7.2. 1.5 Storm Integration 


Storm provides a solution strongly oriented toward intelligent automation of the system. The 
core of their automation suite is the G2 package, which is integrated into their system to provide 
intelligent monitor and control of the launch sequence 


Criteria 

Met 

Comments 

Generic 



• Configurable to support any Bantam 
vehicle 

✓ 


• Adaptable to all spaceports 

✓ 


Monitor and display status of all physical 
interfaces 

✓ 


Monitor and display status of flight soft- 
ware 

✓ 


Provide positive management and control 
of mission specific software/data 



Verify correct upload of mission specific 
software/data 

✓ 


Launch sequence monitor and control of: 

• Ground equipment (interface units, 
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sensors, voice and video, electrical 
systems, fire suppression, weather) 


• All prelaunch vehicle servicing (cryo, 
propellants, gasses, etc) 

✓ 

• Launch vehicle health and status (built 
in test initiation and monitoring) 

✓ 

• Launch vehicle internal sensors (built 
in test) 

✓ 

• OBC checkout and monitor 

✓ 

• Software/data upload verification 

✓ 

• RF downlink interfaces for payload and 
vehicle 

S 

• Payload health and status 

S 

Launch sequence manual control must 
provide 


• Preplanned holds 

s 

• Manual abort at any time (with checks 
to ensure proper safing etc.) 

s 

• Final launch initiation 

s 

• Appropriate range safety interfaces for 
prelaunch phase 

s 

Recording of all vehicle to ground system 
information passed, with time tags 


Capability to archive and retrieve recorded 
data 

✓ 

Interface to telemetry collection for 
launch data 


Support for range safety function 
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Raw 

Score 

Scaled 

Score 

Weighted 

Score 

Comments 

Supplier stability 

3 

60 

6 


Maturity 

4 

80 

12 


Configurability 

4 

100 

5 


Adaptability 

3 

75 

11.25 


Expandability 

4 

80 

4 


Ease of use 

4 

80 

12 


Automation 

5 

100 

15 


Integration 

4 

80 

12 

Considered as combination of L3 and 
Storm 

Platform availability 

3 

75 

3.75 


Total Score 



81 


Cost 


SAV 

113,235 
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7.2.1.6 Software Technology 


STI is well established, with over 15 years of experience in satellite command/control and teleme- 
try system experience. Their product is based on an automated test environment (as are several 
others in the field) which lends emphasis to integration of the ground system software into the 
factory test of the launch vehicle. 


Criteria 

Met 

Comments 

Generic 



• Configurable to support any Bantam 
vehicle 

✓ 


• Adaptable to all spaceports 

✓ 


Monitor and display status of all physical 
interfaces 

✓ 


Monitor and display status of flight soft- 
ware 

✓ 


Provide positive management and control 
of mission specific software/data 



Verify correct upload of mission specific 
software/data 

✓ 


Launch sequence monitor and control of: 



• Ground equipment (interface units, 
sensors, voice and video, electrical 
systems, fire suppression, weather) 

✓ 


• All prelaunch vehicle servicing (cryo, 
propellants, gasses, etc) 

✓ 


• Launch vehicle health and status (built 
in test initiation and monitoring) 

✓ 
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• Launch vehicle internal sensors (built 
in test) 

✓ 

• OBC checkout and monitor 

✓ 

• Software/data upload verification 


• RF downlink interfaces for payload and 
vehicle 

s 

• Payload health and status 

s 

Launch sequence manual control must 
provide 


• Preplanned holds 

s 

• Manual abort at any time (with checks 
to ensure proper safing etc.) 

s 

• Final launch initiation 

s 

• Appropriate range safety interfaces for 
prelaunch phase 

s 

Recording of all vehicle to ground system 
information passed, with time tags 

✓ 

Capability to archive and retrieve recorded 
data 


Interface to telemetry collection for 
launch data 

s 

Support for range safety function 



Raw 

Score 


Supplier stability 


Maturity 




Scaled 

Weighted 

Score 

Score 

60 

6 

80 

12 
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Adaptability 

3 

75 

11.25 


Expandability 

4 

80 

4 


Ease of use 

5 

100 

15 


Automation 

4 

80 

12 


Integration 

1 

20 

3 


Platform availability 

4 

100 

5 


Total Score 



73.25 


Cost 


mm 




31 

























7.2.1.7 Veda Systems 


Veda Systems is the most established company in this field. They have build telemetry systems 
for aircraft, spacecraft and multiple other applications for many years. Their product line is fully 
featured, including both the hardware and software needed to integrate the ground control sys- 
tem. They have provided portions of systems as well as turnkey solutions in the launch control 
area. In addition to launch control they also provide systems used in range safety, which gives 
them additional credibility in this arena. 


Criteria 

Met 

Comments 

Generic 

• Configurable to support any Bantam 

✓ 


vehicle 

• Adaptable to all spaceports 

✓ 


Monitor and display status of all physical 

✓ 


interfaces 

Monitor and display status of flight soft- 



ware 

Provide positive management and control 
of mission specific software/data 

Verify correct upload of mission specific 

✓ 


software/data 

Launch sequence monitor and control of: 

• Ground equipment (interface units. 

✓ 


sensors, voice and video, electrical 
systems, fire suppression, weather) 

• All prelaunch vehicle servicing (cryo. 

✓ 


propellants, gasses, etc) 

• Launch vehicle health and status (built 
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in test initiation and monitoring) 

• Launch vehicle internal sensors (built •/ 
in test) 

• OBC checkout and monitor ✓ 

• Software/data upload verification / 

• RF downlink interfaces for payload and •</ 
vehicle 

• Payload health and status 

Launch sequence manual control must 
provide 

• Preplanned holds S 

• Manual abort at any time (with checks •/ 
to ensure proper safing etc.) 

• Final launch initiation / 

• Appropriate range safety interfaces for V 
prelaunch phase 

Recording of all vehicle to ground system •/ 
information passed, with time tags 

Capability to archive and retrieve recorded S 
data 

Interface to telemetry collection for / 
launch data 

Support for range safety function •/ Veda is particularly capable in this area as 

several range safety functions already use 
some of their system 










players in this field with significant 
experience in multiple types of sys- 
tems. 

Product maturity 

5 

100 

15 

Well established system, being used 
on other launch vehicles and in mul- 
tiple other applications 

Configurability 

4 

100 

5 

Exceptionally robust telemetry and 
calibration tools 

Adaptability 

3 

75 

11.25 


Expandability 

4 

80 

4 


Ease of use 

4 

80 

12 


Automation 

2 

40 

6 

Automation features would have to 
be added on using other COTS tools 

Integration 

5 

100 

15 

Veda has the strongest set of existing 
off the shelf interfaces and products. 
Their products would be strong can- 
didates for the hardware interfaces 
even if another vendor supplied the 
software. 

Platform availability 

4 

100 

5 


Total Score 



77.25 


Cost 



48,000 

This cost figure includes a significant 
portion of the telemetry hardware, 
based on an NT server. 


7.2.2 Government Off the Shelf Systems 
7.2.2.1 Enhanced HOSE System (EHS) 


The EHS is an updated version of the SpaceLab payload control system, intended to provide 
payload control for Space Station experiments. It is also being used as the ground control system 
for the Advanced X-Ray Astrophysical Facility (AXAF), and will be deployed to several other 
sites for Space Station control, including Kennedy and Langley Space Centers. This is an excep- 
tionally capable system, designed for high data rates and handling large quantities of data. It is 
completely data driven, designed to be easily reconfigurable. The system has not been actually 
used for mission support, however it has been tested with real world telemetry. This system will 
be used to support Space Station, so it should be maintained for the life of that program, provid- 
ing added stability. 
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The major question mark with this system is how easily it can be scaled down to be useable in the 
Bantam environment. Also a system this flexible can require a steeper learning curve for opera- 
tions personnel. 

Criteria Met Comments 

Generic 

• Configurable to support any Bantam S 
vehicle 

• Adaptable to all spaceports 

Monitor and display status of all physical S 
interfaces 

Monitor and display status of flight soft- •/ 
ware 

Provide positive management and control / The EHS system is much more capable with 
of mission specific software/data its internal CM capabilities than any of the 

commercial offered systems 

Verify correct upload of mission specific 
software/data 

Launch sequence monitor and control of: 

• Ground equipment (interface units, / 
sensors, voice and video, electrical 
systems, fire suppression, weather) 

• All prelaunch vehicle servicing (cryo, S 
propellants, gasses, etc) 

• Launch vehicle health and status (built / 
in test initiation and monitoring) 

• Launch vehicle internal sensors (built / 
in test) 

• OBC checkout and monitor / 
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• Software/data upload verification 


• RF downlink interfaces for payload and 
vehicle 

s 

• Payload health and status 

s 

Launch sequence manual control must 
provide 


• Preplanned holds 

s 

• Manual abort at any time (with checks 
to ensure proper safing etc.) 

s 

• Final launch initiation 

s 

• Appropriate range safety interfaces for 
prelaunch phase 

s 

Recording of all vehicle to ground system 
information passed, with time tags 

s 

Capability to archive and retrieve recorded 
data 

s 

Interface to telemetry collection for 
launch data 

✓ 

Support for range safety function 



Evaluation Criteria 


Supplier stability 


Product maturity 


Configurability 


Raw 

Score 


Weighted Comments 
Score 


Government 


The system is more custom than any 
of the commercial systems, however 
the built in configurability is excep- 
tionally robust 
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Expandability 

4 

80 

4 

The EHS system is designed to 
handle significantly larger and more 
complex tasks than envisioned for 
Bantam, so expandability should not 
be an issue 

Ease of use 

5 

100 

15 

The system provides an exception- 
ally well defined, consistent user 
interface, and easy to use operator 
configurability 

Automation 

4 

80 

12 


Integration 

5 

100 

15 

This system would require integra- 
tion with one of the off the shelf 
hardware front ends. 

Platform availability 

3 

75 

3.75 


Total Score 



85 


Cost 



500,000 

This cost includes all hardware, 
software, installation and training 
for operators. It does not include 
vehicle specific configurations. 


7.2.2. 2 U. S. Army Systems 

We contacted several branches within the Aviation and Missile Command - Missile Research and 
Development Center to investigate possibilities for technology transfers from Army ground sup- 
port and fire control systems to the Bantam ground support system. We found that their work on 
such systems is limited and invariably peculiar to a specific weapon system. In general, Research 
and Development (R&D) versions of their ground support systems are of a prototype nature, 
while “production” systems are highly optimized for producibility and use of the specific weapon 
system in the field. Whereas R&D versions of missiles may be extensively instrumented, these 
instruments are monitored by ground systems which are test range support oriented and which 
include capabilities in excess of those required for the Bantam Program. 

The Army’s general approach to weapon systems development is worthy of note. During the 
R&D flight phase, comprehensive data is collected to monitor system and subsystem performance. 
These data are analyzed and modifications are made to the weapon system based on the data col- 
lected. Once the point is reached where the weapon system is pronounced ready for fielding, the 
volume of data collected for “analysis” virtually goes to zero (along with the cost associated with 
collecting/analyzing the data). The weapon system is produced in relatively large quantities ac- 
cording to the as-built design resulting from the R&D activity. The resulting system provides 
enough operational data to ensure the soldier in the field that the weapon is in a state of readiness 
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for launch/utilization. It also provides enough data for problem diagnosis. The control subsystem 
is, in most cases, extremely straightforward and extensive enough to get the job done reliably. 

It is suggested that this Army approach to development and operations be seriously considered for 
Bantam development and operations. That is, engineer the overall Bantam system (rocket, 
ground support system, all of it) with the idea in mind that after it proves itself during a reasona- 
bly short R&D period, it will truly become an “operational” space flight vehicle. Once opera- 
tional, it will simply be used to do the job for which it was intended. It will not be constantly 
monitored, tinkered with and optimized as these activities would almost certainly preclude the 
possibility of achieving the $1.5 M per launch cost goal. 

7.3 Rank Ordering 

7.3.1 Ranking by Evaluation Criteria 

What is most striking about this ranking is that in general the vendor scores were quite similar. 
The functionality of the products is similar, but there are some variances in the execution. In gen- 
eral, however, all of these systems are capable of providing the basis for a fully featured DCS. 


Vendor 

Score 

Altair Aerospace Corporation 

88.25 

EHS 

85 

L3 Communications/ Storm Integration 

81 

Integral Systems 

78.75 

Veda Systems 

77.25 

Software Technology 

73.25 

Command and Control Technologies 

60 


7.3.2 Ranking by Cost 


Cost rankings for these systems are based on the commercial list prices given by the vendors. In 
all cases they clearly indicated that the prices given do not reflect any kind of negotiated dis- 
counts, and the final price for an operational system could vary quite substantially from this list. 
Additionally, several assumptions were made in trying to make these costs as comparable as pos- 
sible, and these could significantly change the expected costs. With the exceptions noted in the 
comments the costing is based on software only costs. The reason for this is that all of the com- 
mercial systems can function with essentially any appropriate hardware configuration. This open 
system aspect of the solutions presented is very attractive, and allows the customer to mix and 
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match hardware solutions. 


It should be noted that the expected hardware and software costs for the DCS fit well within the 
cost goals stated in the Ground System Requirements Document. One exception to this is in the 
area of maintenance. It appears that the maintenance costs are likely to be lower in most cases 
than was earlier estimated. As might be expected the lowest cost solutions presented will proba- 
bly take more effort to develop vehicle unique applications, and the higher cost products will gen- 
erally provide a much easier development environment. Each of the vendors offers a range of 
services to assist the customer in integration of the products into final form, but they are all 
committed to developing the expertise in the customer organization rather than building up a de- 
pendent relationship. 


The technical expertise of the personnel at each of the evaluated organizations was impressive. In 
all cases these are the kind of small, highly competent organizations which are very responsive to 
requests for technical assistance. When you call the help line you will talk directly to one of the 
developers who is very familiar with the product. 


Vendor 

Cost 

Comments 

Veda Systems 

48,000 

This cost includes a significant 
portion of the telemetry hard- 
ware, based on an NT platform 

Altair Aerospace Corporation 

70,000 

Software only 

Software Technology 

70,250 

Software only 

L3 Communications/ Storm Integration 

113,235 

Software only (includes G2) 

Integral Systems 

115,000 

Software only 

Command and Control Technologies 

Less than 
100,000 

Costing is an estimate only, 
commercial price list not cur- 
rently available 

EHS 

500,000 

This is a fully installed cost in- 
cluding hardware, software and 
training. 


39 





8.0 Test Plan 


This test plan presents a top level description of what will be tested in verifying and certifying the 
Data and Commanding System, and it includes a description of the internal and external interfaces 
that will be exercised. This activity is considered as critical to Bantam mission success since the 
majority of Bantam systems, both ground systems and flight systems, will be monitored and con- 
trolled via the DCS. This plan focuses on the processes involved and emphasizes consistency 
with the Program goal of defining an overall Bantam launch system which can be efficiently op- 
erated while delivering high reliability. 

In the following sections we first briefly discuss the overall approach to testing including the or- 
ganizational and configuration management aspects. This discussion is intended to establish a 
management framework within which the overall Bantam Program goals are supported by quality 
assurance/testing. Next an overall view of the various automated systems which support the 
Bantam launch vehicle and payload operations is introduced. This discussion emphasizes the need 
for compatibility among the component functional systems as a means of facilitating their testing 
and ultimate effective and efficient operation. This is followed by a discussion which focuses on 
DCS testing within the framework of the overall environment. Finally, we briefly describe using 
the DCS as a tool for facilitating end-to-end testing. 

8.1 Overall 

It is assumed that the launch vehicle developer/operator will define an organization which will 
facilitate developing and then operating the Bantam vehicle in a highly efficient and reliable man- 
ner. This organization will include quality/reliability assurance features which provide at least 
virtual separation between elements which physically develop or change configurations and the 
element which operates the vehicle and supporting systems. Reference Exhibit 8.1-1. This sepa- 
ration enables an 
ongoing check and 
balance environment 
wherein developers 
are required to 
document their 
work and train the 
operations personnel 
well enough for op- 
erations people to 
be able to operate 
and maintain what is 
developed. This 
provides insurance 

that the developers will not evolve as the single points of failure for both the development and the 
operations functions. It provides a natural structure for implementing effective configuration 
management discipline by requiring a handover of what is developed from the development ele- 
ment to the operations element. It separates the development function from the test function, thus 



• DEVELOPMENT 

• COTS ACQUISITION 

• INTEGRATION 

• DEVELOPMENT TEST 


• MAINTENANCE 

• CONFIGURATION CONTROL 

• QA TEST AND CERTIFICATION 

• OPERATIONS PROCESSES 


Exhibit 8.1-1 - Organization 
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enabling meaningful certification of mission readiness. And, it separates the developers from the 
operational system, thus curtailing the tendency to engineer and re-engineer the systems for an 
extended period. Finally, it provides management with a mechanism to control the ultimate cost 
of the systems developed; when the requirements are satisfied, development stops. 

Note 1. Since the knowledgeable launch crew is assumed to be small, the untimely loss of even 
one person from it could present a risk to the overall capability to reliably launch on schedule. 
By ensuring adequate configuration/procedure documentation, effective configuration manage- 
ment and training/cross-training, the risk of attrition can be substantially mitigated 

Note 2. Computer systems are highly susceptible to extended periods of " re-engineering since 
the technology changes rapidly and few developers prefer to work with "old technology”. The 
tendency is to try to update/upgrade at a pace which keeps up with the latest and greatest. Con- 
sidering the cost constraints imposed by the Bantam goals, such extended "development" is 
simply not affordable. 

An overall view of the various automated systems which support the Bantam launch vehicle and 
payload operations is illustrated in Exhibit 8.1-2. In short: the Mission Planning System (MPS) 
sets up the DCS and the flight computer for the mission; the Simulator (SIM) provides the ability 
to test the flight computer/systems and the DCS in an off-line fashion; the on-board flight com- 
puter (OBC) provides vehicle guidance, navigation and control; and the DCS provides the launch 
crew with the ability to test, monitor and control operations throughout the mission life cycle. 



Exhibit 8.1-2 - Automated Systems Overview 
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The various functions of major Bantam data/commanding components are also shown in this ex- 
hibit. (Note, the functions related to building of the transducer calibration database, telemetry 
configuration database and command/script database are shown as within the Mission Planning 
System. Depending on the DCS selected, these functions may be included in the DCS.) 

These systems include a diversity of real-time and non-real-time processing, processing which can 
be accomplished with off-the-shelf hardware/software, processing which is unique to the vehicle 
and the potential for the use of a wide variety of communications media. Some systems are di- 
rectly involved launch support (unshaded), and some are involved only during launch preparation 
(shaded). This diversity coupled with the overarching requirements for low overall cost and high 
reliability provide an imperative for a sound system engineering approach to overall system de- 
sign and selection. This approach must be implemented as early as possible in the process of de- 
signing/selecting the automated support systems to ensure that the component systems will per- 
form their designated functions as well as smoothly interact with other component systems. Some 
objectives of this approach are to achieve: 

• simplicity of overall design, 

• minimum diversity of internal and external interface types, (the optimum would be one type of 
interface, ex., TCP/IP) 

• maximum use of interoperable off-the-shelf hardware and software, 

• low overall cost, Note, a solution for the DCS component which represents the least DCS 
cost may not lead to the least overall cost. If the DCS solution does not interface well with 
the other components, large expenditures may be required to integrate the total system. 

• allocation of functions among systems geared toward simplicity of operations. 

All of these design/engineering objectives contribute to enhance overall system reliability, interop- 
erability, maintainability and affordability, in addition to enhancing the testability of the overall 
system (including the DCS), as well. 
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8.2 Data and Command System 

The organization of the personnel responsible for the DCS follows the fundamental groundrules 
of the overall organization which was discussed above. That is, the development and configura- 
tion change functions are separated from the operations functions to mitigate the risks involved in 
lack of configuration management discipline. The overall organization is headed by an individual 
with the designated authority to approve or disapprove configuration changes. This DCS organi- 
zation is as illustrated in Exhibit 8.2-1. 



Exhibit 8.2-1 - DCS Organization 


During the Bantam development phase it is likely that developers will perform in the role of DCS 
operators for functions such as using the DCS as a monitor and control device for vehicle systems 
tests on the factory floor. Such utilization is natural and assists in debugging and optimizing the 
DCS and providing valuable training on DCS utilization as well. However, it should be consid- 
ered that good developers normally tend to stay in the development professions. It is rare that a 
good developer will transition into an operations job wherein his/her development skills will fade 
quickly. Thus, it is recommended that personnel who will perform the long term operations func- 
tions be assigned to operate the DCS at the earliest practical time in the development phase. This 
early assignment will also facilitate the production of DCS process/utilization documentation 
which will be needed for eventual system testing and certification. Such documentation is not 
really needed by developers (since they built it, they certainly know how to operate it), but it is 
essential to operators (they did not build it, but get stuck with operating it reliably). 

In the real world the DCS development and operational phases will tend to overlap. The DCS 
will evolve through several versions prior to its first utilization for flight support. Hardware, op- 
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erating system and application software changes will be executed with only cursory management 
visibility. The developers will be empowered to do what has to be done to achieve a system 
which meets those requirements which are documented for the DCS and associated operational 
procedures. This activity will inherently include the DCS internal testing which will ultimately 
result in DCS functionality. At some point in this evolution, formalized testing of the DCS must 
be initiated and the system must be placed under configuration management (CM) control. Once 
placed under CM control, changes to the DCS should be curtailed to only those approved by the 
Program Decision Authority of Exhibit 8.2-1. Once placed under CM control, the entire testing 
process described in the following paragraphs should be required after each DCS change. Note, 
this is probably the only way to stabilize the DCS and to stem its cost. It is certainly the only 
way for management to be assured that the DCS is ready for support. 

The process for formally testing the DCS and placing/maintaining it under CM control is illus- 
trated in Exhibit 8.2-2. 



Exhibit 8.2-2 - DCS Test Process 


The following paragraphs discuss the steps of this process. 
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8.2.1 Delivery to Configuration Management 

Prior to the use of the DCS to support any substantial vehicle component, vehicle or payload test, 
the DCS itself should be tested and certified as operationally accurate and reliable. The first step 
in this testing process is to compile a comprehensive set of the as-built system and procedure 
documentation and transfer “ownership” of this documentation to operations. In addition, it is 
necessary for the developers to recognize that any contemplated changes to the system subse- 
quent to this point shall be subject to authorization by the Program Decision Authority. In addi- 
tion, all changes should be documented/rationalized in the Ground System Requirements Docu- 
ment and/or the Operations Concept and Plan. An individual within the operations organization, 
who is recognized as the controller of the configuration, should receive and retain this documen- 
tation. This “operations controller” should ensure thereafter that only authorized changes are 
made to the physical DCS configuration, that all changes are adequately reflected in the documen- 
tation and that a log of the changes be maintained. 

The documentation to be controlled includes: the Ground System Requirements Document, the 
Operations Concept and Plan, operating system revision level descriptions; application revision 
level descriptions; hardware models/versions descriptions; interface and connectivity layouts; 
maintenance procedures; operations procedures and calibration, configuration and command file 
version descriptions. The objective of this documentation and of keeping a record of changes to 
it is to ensure that any specific configuration can be reconstructed in case of an anomaly. 

The physical system to be controlled includes: all DCS hardware components, all internal inter- 
faces and connections, all DCS software components, calibration files, telemetry configuration 
files, command files and test scripts. Note, in the real world last minute low level changes may 
occur which require minor changes to the DCS. (For example, a last minute change-out of an 
on-board transducer could require a change to the calibrations database file.) In these cases, 
good sense dictates that the change must be made for expediency’s sake and potentially without 
the benefit of exhaustive system retesting. The important point is that all such changes be 
brought to the attention of someone who realizes the potential ramifications of the change, prior 
to making the change, and that this person decides on any retesting requirements prior to con- 
tinuation of the activity at hand Referencing Exhibit 8.2-1, Level 2 leadership should agree on 
the handling of all changes, while Level 1 leadership should authorize any last minute change 
which could conceivably compromise property, safety, etc. 

8.2.2 Installation 

The operations controller is responsible for DCS hardware and software installation - in accor- 
dance with the specific configuration documentation. He/she (and other operations personnel) 
may accomplish this by watching/assisting the developer(s) actually to perform the installation. 
The operations controller is delegated this installation responsibility to ensure that someone 
other than the developers knows how to do it. This mitigates the risk of dependence on the de- 
veloper as a single point of failure. 

8.2.3 Testing 

This testing is to ensure that the DCS itself and the operational procedures perform as needed and 
that they are reliable for the conduct of vehicle component, vehicle and payload testing and mis- 
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sion operations. Testing is in “black box mode”. That is, testing is against the functional re- 
quirements of the system and procedures, not the internal designs thereof. 

Testing is done by the operations team which may be comprised of multiple entities (ex. develop- 
ers and operators) under the direction and leadership of the operations controller. 

The objectives of the testing are: 

• To validate that the requirements of the Bantam System Technology - Ground System Re- 
quirements Document have been implemented successfully Note, each of the capabilities of 
the DCS and procedures should be directly traceable to the requirements document and/or 
the operations concept and plan. The paradigm should be that if there is no documented re- 
quirement, the capability is unneeded and unaffordable. 

• To validate that the requirements of the Bantam System Technology - Operations Concept 
and Plan have been implemented successfully 

• To validate that the DCS internal and external interfaces are functional 

• To validate and certify correct implementation of the documented hardware and software 
configurations. 

The elements involved in testing/certifying that the DCS internal processes function as required 
are illustrated in Exhibit 8.2-3. 
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Exhibit 8.2-3 - DCS Test Configuration 
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Note, the simulator shown in this exhibit is a subset of the “simulation” discussed elsewhere in this 
document. The simulator used for DCS testing/certification is a data stream generator which 
produces known values for all of the data parameters passed over all of the interfaces into the 
DCS. In addition, this simulator provides the capability to ensure accurate receipt and analysis of 
DCS-generated commands. It is highly advisable to ensure that the DCS is capable of performing 
all of its functions in this isolated/off-line environment prior to testing the DCS with other ground 
system components. Since simulators are quite expensive to develop, this is an important reason 
to acquire a DCS which is proven and off-the-shelf and which has a proven simulator package 
available. 

The ultimate DCS test configuration is shown in Exhibit 8.2-4 wherein all of the external inter- 
faces are exercised. 



ACRONYMS: 

C -Sensor* = Control Sensors 

E-Sensors = Environment Sensors 

AV = Avionics 

CMD = Command 

RT = Real-Time 

NRT = Not Real-Time 


LEGEND 



Exhibit 8.2-4 - Integrated Test Configuration 

This configuration defines the setup of a typical simulation as defined elsewhere in this document, 
and it reflects the flight/mission support configuration as well. This configuration provides oppor- 
tunities for testing of all of the DCS and procedure capabilities. Note that by including the actual 
flight computer as part of the simulation component of the Ground System, it removes the guess- 
work from testing/simulating the DCS-OBC interface. This is as opposed to emulating the OBC 
within the simulation. 
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8.2.3.1 Preparation 

The testing is conducted using scripts developed to ensure that each requirement of the Bantam 
System Technology - Ground System Requirements Document have been implemented success- 
fully. In addition, these scripts are to ensure that the DCS functionalities required in the Bantam 
System Technology Project, Ground System Operations Concept and Plan have been imple- 
mented. These scripts are developed, reviewed, and baselined prior to the test phase. (Test script 
formats are available in HOSE-SYS-121.) Test scripts tend to evolve more fully during the actual 
testing. A review of test scripts prior to the actual testing should ensure that all appropriate sce- 
narios are tested, in addition to validating that script steps are correct. 

The operations controller is responsible for verifying that the physical configuration of the hard- 
ware, software, databases, simulator, test scripts and communications matches the documented 
configuration. This can be practically accomplished during installation. 

Having verified that the physical and documented configurations are the same, the operations 
controller certifies the configuration in writing. (Forms for this certification are available in 
HOSE-SYS-121.) 

8.2.3.2 Execution 

The testing involves the target DCS hardware and software. (Target-like hardware and/or soft- 
ware can be used for demonstrations, but not for DCS certification.) Input data for validation of 
the functionality of the DCS is generated by the Simulator. Calibration, telemetry configuration 
and command database information originates from either a test database or an actual mission 
database. 

The test team executes tests according to the appropriate scripts, testing as many steps as possible 
for each script even when problems are encountered. Problems are documented on Problem Re- 
ports which are reviewed by all appropriate management. Management retains the authority to 
determine whether a problem must be fixed or if a work-around will be adopted. 

As each test script is executed, the test results are recorded in a test log. (Test log format is 
available in HOSE-SYS-121.) In general, this documentation includes test results such as screen 
dumps and reports, support documentation/comments and problem reports. These data are re- 
tained for future reference. 

8.2.3.3 Completion 

A review should be conducted to mark the end of a logical set of tests. The purpose of this re- 
view is to ensure that the test results are visible to the appropriate management, development per- 
sonnel and operations personnel. 

8.2.3.4 Regression Testing 

When testing is the result of configuration changes which were triggered by Problem Reports, re- 
gression testing must be performed according to the criteria of Section 8. 2. 3. 2. In this case, it is 
necessary also to ensure that all documentation is kept up-to-date by the methods described in 
Section 8.2.3. 1. 
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8.2.3. 5 Documentation 

The aggregate of the documentation described in Sections 8.2.3. 1 through 8. 2. 3. 4 should be 
compiled and filed for future reference for each configuration tested. (This documentation consti- 
tutes the basis for DCS system certification.) 

8.2.4 End User Testing 

The testing described above is intended to ensure that the DCS meets or exceeds the requirements 
for primarily the monitoring and control of the launch vehicle. It is probable that Bantam custom- 
ers (payload developers) may also have requirements for using the DCS to monitor and control 
some aspects of the payload. For this reason, it is recommended that a practical number of pay- 
load developers be invited to test the DCS as early as possible in the DCS development process. 
Such interaction with payload developers may well define additional DCS requirements as well as 
be a valuable marketing tool for Bantam launch services. 

8.2.5 Readiness Review 

A review should be conducted to mark the end of testing and to provide visibility of the readiness 
of the DCS to provide support for vehicle component, vehicle and payload test/mission activities. 
The purpose of this review is to ensure that the appropriate management, development personnel 
and operations personnel are aware of the successful conclusion of DCS testing as well as any 
work-arounds which have been implemented in response to problems encountered during testing. 
In addition, this review serves to reinforce the stability of the system by ensuring that all parties 
are aware that the system is in a fixed state of configuration control pending approval of the Pro- 
gram Decision Authority for any change. 

9.0 Communications 

The communications needed for conducting mission preparation and operations can be a substan- 
tial cost driver. However, by exploiting modem technology and by designing operational proce- 
dures to accommodate this technology, these costs can be held to an adequate minimum. This 
section presents a framework for designing/specifying the ground systems (as well as flight sys- 
tems) to accomplish efficient communications throughout the mission life cycle. Alternatives are 
presented for specific implementation cost / performance optimization. 

Typical activities which drive communications requirements for the various phases of the mission 
life cycle are shown in Exhibit 9.0-1. This exhibit also presents suggested communication media 
for accommodating the stated requirements as well as approximate costs which can be anticipated 
for the suggested approaches. The following paragraphs expand on these suggestions. 
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MISSION 

PHASE 

TYPICAL ACTIVITY 

COMM 

MEDIA 

COST / COMMENT 

MISSION 

PLANNING 

• TRIAL RUNS OF MPS (FROM 
USER SITE) TO ENSURE BANTAM 
VEHICLE SUITED FOR PAYLOAD 

• ALL MISSION PLANNING AND 
SCHEDULING “PAPERWORK’ 

INTERNET 

• INTERNET COST NEGLIGIBLE 

• MPS INCLUDED IN BANTAM 
VEHICLE OPERATOR'S WEBSITE 

• "PAPERWORK" ALL VIA WEBSITE 
ELECTRONIC DATA EXCHANGE 

INTEGRATION 

• REMOTELY VIEW PHYSICAL 
INTEGRATION (VIDEO) 

* REMOTELY VIEW/ANALYZE 
PHYSICAL INTEGRATION DATA 
FROM DCS 

INTERNET OR 
DEDICATED 
CIRCUIT 

• INTERNET DATA/VOICE/VIDEO 
INSTALLATION COSTS APPROX. 
$1K 

• INTERNET OPERATIONS COST 
NEGLIGIBLE (STD BANDWIDTH) 

• DEDICATED CIRCUIT DATA, 
VOICE, VIDEO INSTALLATION 
COSTS ROM $30K FOR FRAC T-1 

• DEDICATED CIRCUIT COST 
APPROX $1-2K PER MONTH FOR 
FRAC T-1 

COUNTDOWN, 
LAUNCH AND 
ASCENT 

• REMOTELY VIEW/ANALYZE 
PERFORMANCE DATA FROM DCS 

• REMOTELY VIEW OPERATIONS 
(VIDEO/VOICE) 

ON-ORBIT 

OPERATIONS 

• REMOTELY VIEW/ANALYZE 
PERFORMANCE DATA FROM 
SPACECRAFT 

• REMOTELY COMMAND 
SPACECRAFT 

TDRSS OR 
PRIVATE DISH 
FOR SPACE TO 
GROUND LINKS 

• TDRSS: INSTALLATION ROM $0, 
DOWNLINK APPROX $13/MIN, 
UPLINK APPROX S26-39/MIN 

• PRIVATE DISH: INSTALLATION 
ROM $10K AND NEAR $0 PER 
MONTH 

• DISTRIBUTE DATA TO/FROM 
REMOTE SITES 

• COMPILE COMMANDS FOR 
UPLINK 

INTERNET FOR 

GROUND TO 
GROUND LINKS 

• INTERNET INSTALLATION AND 
OPERATIONS COSTS NEGLIGIBLE 
(STD BANDWIDTH) 


Exhibit 9.0-1 - Mission Life Cycle Communications 


Mission Planning Phase - The primary activities of this phase are: (1) assuring the prospective 
payload customer that the Bantam vehicle is suitable for his/her payload and (2) exchanging tech- 
nical and management information relative to scheduling, interfacing, cost, constraints, spaceports 
and the like. The vast majority of this information is suitable for exchange via the Internet - with 
proper security precaution. For example, the vehicle operator’s website would do well to include 
information which provides guidance on how the prospective customer can engage the vehicle 
operator for providing launch services. The Mission Planning System module for calculat- 
ing/displaying vehicle performance based on payload and orbital parameters could be accessible 
via the website to allow customers to satisfy themselves of Bantam suitability without intensive 
vehicle operator personnel involvement. All of the necessary forms (“paperwork”) associated 
with launch permits, analytical integration, etc. should be completed in the paperless on-line envi- 
ronment. Since virtually every prospective Bantam customer will have Internet access, the im- 
plementation cost for the customer is considered to be zero. The cost for the vehicle operator to 
implement the website capabilities described is estimated at around $10K. 

Integration Phase - The primary activities of this phase are: (1) transport of the payload to the 
launch site, (2) physical integration of the payload and vehicle, (3) testing to ensure that interfaces 
(mechanical, electrical and electronic) are functional and (4) testing to ensure the launch readiness 
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of the vehicle and payload. Transport of the payload can be facilitated/tracked using the informa- 
tion exchange capabilities of the Internet. Physical integration is often video monitored and re- 
corded. Should the payload developer or some key personnel of the vehicle developer be located 
at a site remote from the integration site but wish to “witness” the integration or help in trouble- 
shooting, video could be made available at the remote site. Internet-based video can be imple- 
mented for under $2K. If full motion video is desired, the equipment needed can be purchased for 
around $20K; this same equipment could be rented/leased for a small fraction of this cost. In 
addition, full motion dedicated circuit costs can be expected to include approximately $4K for cir- 
cuit setup (both ends) and up to $2K per month if continuous service is desired. 

Integration testing frequently involves data acquisition at the integration site - performed by the 
DCS. If this data is required to be monitored in real-time by personnel at a remote site(s), both 
Internet-based and dedicated circuit communications solutions are readily available. The majority 
of the DCS systems surveyed support this remote monitoring via the Internet for an additional 
DCS cost of around $2K. In this case communications costs are negligible. If data refresh rate 
and/or data timeliness is a substantial issue, dedicated circuit services may be acquired. In the 
worst case (considering that both full motion video and data are desired), additional equipment 
purchase costs of around $10K can be expected. (This $10K cost can be avoided if video or 
other multiple channel requirements do not exist.) Dedicated data circuit setup costs (without 
video) are about $1K with recurring costs of about $300 per month (continuous service). Stan- 
dard telephone service is suggested for remote voice requirements. 

Countdown, Launch and Ascent Phase - The primary activities of this phase are: (1) prelaunch 
testing of the integrated vehicle and payload, (2) preparing the vehicle for launch (fueling, etc.), 
(3) monitoring preparations for launch via the DCS, voice and video, (4) initiating the launch se- 
quence via the DCS and (5) monitoring ascent via the DCS and video. Launch site communica- 
tions are considered to be self contained within the launch site systems. If the DCS data monitor- 
ing activities or video monitoring activities are desired to be observed from a site remote from the 
launch site, the remote communications options discussed above apply. Standard telephone serv- 
ice is su gg ested for remote voice requirements. 

On-Orbit Operations Phase - The primary activities of this phase are highly payload dependent. 
However, if there are requirements for data (or video) downlink and/or command/data uplink, 
several options are available currently and more options may be available in the future. NASA 
can provide downlink and uplink services using the Tracking and Data Relay Satellite System 
(TDRSS) for the prices shown in Exhibit 9.0-1. These services are managed using a demand ac- 
cess approach wherein the communications must be precoordinated and the TDRSS capabilities 
are utilized on a first come first served basis. Single access services may be available through the 
TDRSS for costs of $90 - $180 per minute. This approach requires substantial upfront planning 
during the payload design and development phases and close coordination with the NASA God- 
dard Space Flight Center during these phases is suggested. 

Private downlink/uplink communications can be established using equipment costing from $10K 
and up. This includes use of a private dish and an operations procedure wherein the orbiting 
payload dumps/uploads data as it passes over the dish, Again, this approach requires substantial 
upfront planning during the payload design and development phases but its recurring communica- 
tions costs can be nearly zero. 
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Although commercial, space-based communications service providers are currently focused on the 
terrestrial communications market, satellite to satellite relay services are maturing and should be 
available from a larger number of sources in the future. Most of the technologies needed for such 
services exist and activities are in motion to mitigate current regulatory restrictions. 

The communications ground segments of most on-orbit payload operations scenarios can be ac- 
complished utilizing the current Internet. And, since the Internet is so universally established and 
since tools for its usage are so extensive (and inexpensive), it is recommended that all payloads 
and ground support schemes be designed to exploit Internet usage. In the future, the bandwidth 
capability of the Internet will be upgraded with the introduction of the Internet n, and Internet II 
will most likely be made available for science support as a priority. In those cases where data 
rates practically exceed the effective standard Internet capability, dedicated circuits can be ob- 
tained for costs as estimated above. (Note, cost is directly proportional to bandwidth.) 


10.0 Conclusions 

The following conclusions were drawn in the conduct of this study. 

1. A fully functional Bantam DCS can be acquired from off-the-shelf products; expensive DCS 
development is unnecessary. 

2. The cost goals of the Ground System Requirements Document relative to the development 
phase can be achieved. The cost goals relative to the operations phase can be easily achieved. 

3. All of the systems surveyed can meet the pass-fail criteria described in Section 7.1.1. 

11.0 Recommendations 

This section presents recommendations derived in conducting the study. The “overall” recom- 
mendations are most appropriately considered as suggestions to NASA, while the “DCS” recom- 
mendations are primarily to the vehicle developers. 

11.1 Overall 

Recommendations relative to the overall Bantam Program are: 

1. Consider developing a standard development flight instrumentation payload as a specification 
for the Bantam Cycle 2 competition. This may simplify the physical and electronic interfaces 
to which the launch vehicle developers are to build their vehicles, and it may in turn result in 
an overall Bantam Program cost avoidance. 

2. Consider defining a standard DCS as a specification for the Bantam Cycle 2 competition. This 
may also simplify the interfaces to which the launch vehicle developers are to build their vehi- 
cles, it will reduce the redundancy of each vehicle working on his own DCS, and it may in 
turn also result in an overall Bantam Program cost avoidance. 

3. Consider establishing a working group of representatives from the various Bantam contrac- 
tors. The purpose of the forking group would be to establish Bantam areas where design 
commonality can benefit all participants. For example, they should discuss a common basic 
vehicle to payload interface for the demonstration phase. This may result in an overall Ban- 
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tarn Program cost avoidance by eliminating redundant work on such interfaces. A common 
interface for the operational phase may enhance the value of the vehicle to potential custom- 
ers, since it allows them to develop payloads to a single standard without having to worry 
about what carrier they will be using. (This can also serve to spur price competition among 
the carriers.) 

11.2 Data and Command System 

Recommendations relative to the Bantam DCS are: 

1. The vehicle developers should move quickly to select a ground system supplier/integrator and 
involve them in the preliminary design process. Many decisions which are made early in the 
design process could significantly lower ground system costs without significant effects on the 
final cost of the vehicle. It is clear that several off the shelf systems exist which can be imple- 
mented easily and will allow the operational goals of the ground system to be achieved. 

2. The vehicle developers should adopt the paradigms suggested in the Principles Section 
(Section 3.1) of this document. 
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